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AIRCRAFT DATA COMMUNICATIONS SERVICES FOR USERS 

CROSS REFERENCE TO RELATED APPLICATIONS 

This application is a continuation-in-part of U.S. Patent Application Serial No. 
5 09/3 12,01 1 filed May 14, 1999, entitled "Method and Apparatus for Data 

Communication Utilizing the North American Terrestrial System". This application is 
related to U.S. application entitled "Aircraft Data Services", which is filed on even date 
herewith. These applications are co-pending and commonly assigned. 

10 BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention generally relates to wireless data communication services. 
It particularly relates to aircraft data communication services for users. 

15 

Background 

Existing data communication services, particularly for aircraft systems, are 
generally limited to particular applications. These particular applications provided by 
non-pubUc communication systems include ground flight recorder development, air 
20 traffic control operations, maintenance operations, position monitoring (e.g., global 
position satellite systems - GPS systems), coUision avoidance, aircraft surveillance, 
weather radar, in-flight entertainment and other specific applications. 

Existing data communication services for aircraft passengers are similarly limited 
to particular communication protocols and software/hardware systems, therein limiting 
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convenience, affordability, and efficiency. These user communication protocols and 
systems include the Terrestrial Fhght Telephone System (TFTS) and other private 
communication protocols and systems. These private systems require specialized, high- 
cost antenna equipment and power control systems or an inconvenient, invasive 

5 passenger ID assignment system to make use of public communication systems such as 
the cellular communication system or the public switched telephone network (PSTN), or 
require high-interference systems such as the existing amplitude modulation (AM) 
aircraft communication systems. Based on these existing limitations of non-pubhc 
commimication systems, a need exists to enable flexible, seamless data commimication 

10 for aircraft systems using pubUc wireless networks to increase affordability and 
efficiency. 

SUMMARY OF THE INVENTION 

The previously mentioned disadvantages are overcome by providing an efficient, 
15 flexible, and convenient method and system for providing data communication services 
for users. In accordance with embodiments of the present invention, a data 
communication server, including a plurahty of interface units, facilitates data 
communication between a moving object and one or more ground terminals via a radio 
communication path. The data communication server estabhshes the radio 
20 communication path over one of a plurahty of wireless data networks including terrestrial 
and satellite data networks and may include an object-oriented software architecture. 
Additional features of the present invention include personal data communication 
services for users and operational data services for the moving object. 
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Additional features of the present invention include a system for providing 
communication services including a data communication server, co-located with a 
moving object, for establishing a radio communication path between a moving object and 
a ground station, the data communication server including software architecture including 
5 software functional layers, the layers including a system resources layer, a system 
services layer, an apphcation programming interface layer, and an application layer. 

Further features of the present invention include a method of providing wireless 
data communication services including establishing a radio communication path between 
a moving object and a ground station using a communication server co-located with the 
10 moving object, the data communication server including software architecture including 
software functional layers, the layers including a system resources layer, a system 
services layer, an application programming interface layer, and an apphcation layer. 

BRIEF DESCRIPTION OF THE DRAWINGS 

15 Fig. 1 is a block diagram showing a communication system architecture in 

accordance with an embodiment of the present invention. 

Fig. 2 is a block diagram of an alternative communication system architecture in 
accordance with an embodiment of the present invention. 

Fig. 3 is a block diagram showing the data link options in accordance with an 
20 embodiment of the present invention. 

Fig. 4 is a block diagram showing the data Unk options via a satellite network in 
accordance with an embodiment of the present invention. 
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Fig. 5 is a block diagram of a communication system architecture using a satellite 
network in accordance with an embodiment of the present invention. 

Fig. 6 is a block diagram of an alternative communication system architecture 
using a satellite network in accordance with an embodiment of the present invention. 
5 Fig. 7 is a block diagram of another altemative communication system 

architecture in accordance with an embodiment of the present invention. 

Fig. 8 is a block diagram of another altemative communication system 
architecture in accordance with an embodiment of the present invention. 

Fig. 9 is a block diagram of another altemative communication system 
10 architecture in accordance with an embodiment of the present invention. 

Fig. 10 is a block diagram of another altemative communication system 
architecture in accordance with an embodiment of the present invention. 

Fig. 11 is a call flow process diagram of a communication system architecture in 
accordance with an embodiment of the present invention. 
15 Fig. 12 is a block diagram of the software infrastructure for the data 

communication server in accordance with an embodiment of the present invention. 

Fig. 13 is a software function layer diagram of a communication software 
infrastructure for the data communication server in accordance with an embodiment of 
the present invention. 

20 Fig. 14 is a block diagram for the service logic architecture of a communication 

software infrastructure for the data communication server in accordance with an 
embodiment of the present invention. 
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Fig. 15 is an application software function layer diagram of a communication 
software infrastructure for the data communication server in accordance with an 
embodiment of the present invention. 

Fig. 16 is a block diagram of an alternative software infrastructure for the data 
5 communication server in accordance with an embodiment of the present invention. 

Fig. 17 is a property table of a communication software infrastructure for the data 
communication server in accordance with an embodiment of the present invention. 

Fig. 18 is an alternative property table of a communication software infrastructure 
for the data communication server in accordance with an embodiment of the present 
10 invention. 

Fig. 19 is an altemative property table of a communication software infrastructure 
for the data coramunication server in accordance with an embodiment of the present 
invention. 

Fig. 20 is a method table of a communication software infi-astructure for the data 
15 communication server in accordance with an embodiment of the present invention. 

Fig. 21 is an altemative method table of a communication software infrastructure 
for the data conmiunication server in accordance with an embodiment of the present 
invention. 

DETAILED DESCRIPTION 

20 

Svstem Components 

FIG. 1 illustrates a representative data communication system architecture 100 in 
accordance with embodiments of the present invention. The system 100 includes an 
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aircraft data server 110, cabin distribution system (CDS) 150, and bearer services systems 
components 1 80. The server 110 may be used as the main processor unit that provides 
programmable control over the routing, scheduUng, and use of the system 100. 

The CDS 150 provides access to the data services provided by the system 100 via 

5 the server 110. The CDS may include a plurahty of components including a Human 
Interface Module (HIM) 155, a Passenger Access Server (PAS) or Terminal Server (TS) 
(not shown), and other components knov^n to those of skill in the art for forming a Cabin 
Communications System (CCS). The HMs 155 may be laptop computers with 
appUcations for logging data and interfacing with the server for data transfers. The 

10 PAS/TS, which may advantageously be a part of the server 1 10 or an external device, can 
provide dial-up connectivity to the passenger seats for data service access. 

The bearer systems 180 can provide the server 1 10 with the data connectivity to a 
plurality of ground-based servers. The bearer systems 180 may include a plurality of 
components including an Airborne Communications Unit (ACU) 205, a Wireless Gate- 

15 link system (WGS) 182, a Satellite Data Unit (SDU) 195, and a Terrestrial Fhght 
Telephone system (TFTS) 200. The WGS 182 may be, for example, a wireless LAN 
transceiver (as shown in FIG. 1) based on the IEEE 802.1 1 specifications which can 
allow transfer of high-speed data to the server 1 10 in the airport when the aircraft 
(moving object) is on the ground. The ACU may act as the gateway to a ground-based 

20 data center via the North American Terrestrial System (NATS) network. Although the 
present invention is described with reference to the NATS network, the NATS network is 
solely exemplary and alternative communication networks may be used for providing air- 
to-ground data commimication services. 
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The SDU may provide access a Satellite Communications (SATCOM) Satellite 
Bearer Service. The TFTS is used to access the European land-line telephone network. 

System 100 may include a plurality of components to provide higher data 
bandwidth and passenger access technology for facilitating data applications, examples 
being Internet Web browsing and email retrieval. These components include Direct 
Broadcast Service (DBS) satellite decoder 152, passenger cabin dial-up access system 
151, and the WGS 182. Other components of system 100 can help facilitate data 
communications over the existing NATS data network. 

The server 110 may include a CPU (not shown) comprising, for example, an Intel 
Pentium Pro, or equivalent processor system. The CPU provides multiple functions 
including, for example, interfacing various applications for data storage and retrieval and 
managing various data communications interfaces for data transfer to the ground-based 
servers. 

The server 110 may include a plurahty of interface units for interconnecting to 
various data networks. These interface units may comprise a plurality of discrete I/O 
boards or a single integrated board. Alternatively, the server 1 10 may include 
commercial off-the-shelf (COTS) network cards to provide data communications services 
for the system 100. 

The plurality of interface (I/O) units may include an Ethernet interface unit 115, 
modem 120, communications (COM) port 135, Integrated Services Digital Network 
(ISDN) Basic Rate Interface (BRI) port 130, Primary Rate Interface (PRI) port 125, 
ARINC-429 (Aeronautical Radio, hic.) bus interface unit 145, and ARINC-573 bus 
interface unit 140. The Ethernet unit 115 may include ports for interconnection to the 


HMs 155 and to the external terminal station (TS), and may be used to connect to the 
wireless local area network (LAN) transceiver 182 providing a high-speed datapath to 
ground terminals while the aircraft (moving object) is on the ground. Alternatively, a 
COTS Ethernet card attaching to an external hub (not shown) may be used. 

5 The modem 120 and COM port 135 are used to enable the server 110 to provide 

dial-up connection to the ground-based servers via the NATS network. Additionally, in 
the packet data mode for system 100, the COM port 135 can be used to connect the server 
1 10 to the ACU 205 directly. 

The PRI port 125 and BRI port 130 allow users (passengers) to establish dial-up 

10 internet protocol (IP) connections, via the CDS 1 50, when the system 100 offers Web 
browsing, email retrieval, and other passenger-related data services. The BRI port 130 
may also be used as one of the system 100 link options when operated in the packet data 
mode. This mode is entered when a call is established between the server 1 10 and the 
ACU 205, and the bearer channel (B-channel) is operated in 64-Kbps unrestricted mode. 

15 Once the call setup is completed, data is transferred without alteration allowing data-link 
protocols, an example being Point-to-Point Protocol (PPP, RFC-1548), to be used to 
encapsulate the IP packets sent to and from the ACU. This mode may also be referred to 
as the transparent bearer service. 

The ARINC-429 bus interface 145 can be used by the server 1 10 to receive data 

20 from a plurality of on-board management systems and to allow access to an additional 
bearer service via the existing Aircraft Commimications Addressing and Reporting 
System (ACARS) messaging capabilities or Satellite Data Unit (SDU) if so chosen. The 
server 1 10 can also receive data transmitted from the ground via ACARS using the 
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interface 145. Advantageously, the interface 145 has at least one transmit port to 
interface with an ACARS mobile unit (MU) 210 and at least two receive ports, one to 
receive management data from the Aircraft Condition Monitoring Systems (ACMS) and 
one to receive data from the ACARS. Additional receiving ports can be added as need to 

5 provide ftirther management appHcations to monitor data from on-board sensors via the 
ARINC-429 bus interface 145. 

Additionally, the system 100 may include a digital satelhte system (DSS) 
interface unit (not shovra) to provide broadband packet data service at faster rates than an 
Tl/El rate. The broadband data service can use a Direct Broadcast Satelhte (DBS) to 

10 transmit and receive packet data, including a DSS channel coding scheme, quadrature 
phase shift keying (QPSK) modulation and R-S forward error correction, MPEG-2 
technology for compressing and transporting (data link layer) the digital video data, and 
low-profile antenna and DSS decoder PC board^ox to receive and decode the DSS 
signal. Other broadband methodologies may include, but are not limited to MPEG-4 (e.g, 

15 H.263, H.261) and other compression techniques including compression techniques that 
are standards comphant or proprietary. 

The ACU 205 enables air-to-ground communication using the existmg NATS 
network. Advantageously, two types of ACU can be used based on the type of interface 
to the CDS 150, examples being a type 496 and a type 4300/8600. Type 496 has 12 

20 ISDN BRI ports that support direct interface to BRI handsets, and type 4300/8600 

interfaces to the CDS 150 by connecting to the Cabin Telecommunications Unit (CTU) 
161 via ISDN PRI port 125. The data link to the ACU 205 may be via one of the B 


channels on the same PRI that carries voice traffic to the ACU 205 requiring the server 
1 10 to request a B-channel call to the ACU 205 via the CTU 161. 

Both types of ACU can include a baseband unit (BBU), radio frequency unit 
(RFU), and a power supply unit (PSU). The BBU advantageously controls the data hnk 

5 connection from the aircraft to the nearest ground station. Both types of ACU will accept 
two different data link connection types from the server. In the non-packet data mode, an 
asynchronous (Async) voice-grade modem dial-up via a B-channel ISDN link using a 
data access unit (DAU) 202 can be used. In the packet data mode, a transparent B- 
channel data link can be used. 

10 In the non-packet data mode, the link operates with the BBU having an internal 

modem to provide V32N22 capability interfacing with the modem on the server 1 10. 
In the packet data mode, the server 1 10 can first encapsulate the IP packet in a PPP data 
frame and send it to the BBU using the clear B channel data service. Once the BBU 
receives the PPP frame, the BBU will strip off the PPP header from the PPP packet, and 

15 repackage the remaining IP packets into the radio (RF) framing structure. The server 110 
then modulates the data with phase shift keying (PSK) and up-converts the signal to radio 
frequency for the RFU to transmit to the ground. The RFU provides needed signal 
amplification for transmitted and received signals, and the PSU provides direct current 
(DC) power derived from the aircraft (moving object) power source. 

20 The Human Interface Modules (HIMs) 155 can be laptop PCs, for example, used 

by crew and operational personnel as the gateway to the system appUcations via a 
standard graphical user interface (GUI). HMs 155 can be housed, for example, in an 
adapter shell that allows connection to a common docking station, the adapter shell 
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providing the interface between the HIM 155 and the docking station and equipped with 
an Ethernet interface to connect to the server 110. 

System Data Link Interface Options 

The communication system, including server 110, has access to ground-based 
data servers via several data bearer services as illustrated in FIG. 2. These data bearer 
services can include wireless LAN services 250, NATS packet or voice-band data 
services 255, sateUite data services 265, terrestrial flight telephone services (TFTS) 270, 
and direct satellite system services (DSS) 275. 

FIG. 3 illustrates the data link options for the server and for the groimd-based 
customer premises equipment (CPE) using the NATS network. Advantageously, there 
are three data link options for the server 325 to connect to the ACU for providing data 
communication services to the ground. The first option is establishing a point-to-point 
protocol (PPP) connection 310 between the server 325 and the CPE 492 via a voice-grade 
dial-up over the existing NATS voice network. Other components of the data link may 
include a data access unit (DAU) 340, ACU 370, ground station 400, public switched 
telephone network (PSTN) 430, 480, and ground data gateway (GDG) 465. The system 
can use PPP as the end-to-end Hnk layer protocol as if a direct connection exists between 
the server and the CPE. 

The other two options operate in the packet data mode. A regular traffic channel 
of the NATS network will be used to carry the packetized data and a circuit switch call is 
performed to maintain the channel for the duration of the packet transfer. The first packet 
mode option 310 uses the ISDN BRI interface unit of the server 325 by connecting the 
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server 325 to the type 496-BBU, part of ACU 370, via the BRI Une. To estabHsh a radio 
communication path, the server 325 can send a call setup request message to the 496- 
BBU, and the 496-BBU can request the ground station for a traffic channel before the 
496-BBU establishes the call with the server 325. After a channel is allocated, the 496- 

5 BBU returns a call-estabhsh-message back to the server 325, and an end-to-end ISDN 
data call is estabhshed between the server 325 and the 496-BBU. Subsequently, IP 
packets are transferred using the B channel by encapsulating them inside the PPP frame. 

The second packet data option 305 uses ACU 370 of type 4300/8600. In this 
option, the server 325 is connected to the 4300/8600-BBU via the CTU 350 using the 

10 ISDN El PRI link. The call setup then follows a similar scenario as to the first packet 
data option that used BRI except that the CTU 350 is used to estabUsh the call to the 
BBU, part of ACU 370, over one of the B-channels. At the BBU, IP data packets are 
channel encoded and encapsulated in radio frequency (RF) data frames. Subsequently, 
the data packets are modulated onto a radio frequency and sent to the Ground Station 

15 (GS) 400. At the GS 400, the data packets are sent along to the Ground Data Gateway 
(GDG) 465 via a Frame Relay (FR) network. The GDG 465 advantageously transfers the 
IP packets to different networks by proper protocol conversions, and receives all ground- 
to-air packet data call requests, sending them to the destination air terminal via an 
associated GS where a radio link is estabhshed by the air terminal. 

20 Additionally, an alternative system architecture 330 can be used for a packet data 

mode allowing aggregation of multiple radio links to provide higher data throughput. 
This higher data rate can be achieved by tunneling the PPP frame from the server 325 to 
GDG 465 via a Layer Two Tunneling Protocol (L2TP). L2TP tunneling allows the PPP 
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session to be initiated by the server 325 and terminated at the GDG 465, not the BBU 
(part of ACU 370), allowing the server 325 and GDG 465 to establish multiple PPP 
sessions over multiple radio links. The GDG 465 enables the server 325 to negotiate a 
PPP Multilink Protocol (MP) with GDG to bundle all the PPP sessions together to form a 

5 higher bandwidth virtual pipe. 

Tunneling (L2TP) provides a number of unique advantages for the system. These 
advantages include using the existing infrastructure to make the addition of server data 
communication services transparent to the existing Air-Ground network until the IP 
packet arrives at the GDG. Further advantages include the following: 1) lower 

10 development costs because development is only needed at the two ends, server and GDG, 
and the existing serial line internet protocol (SLIP) on the BBU can be used for 
dehvering L2TP packets; 2) allowing single point of processing for IP address 
assignment and packet filtering because only the GDG will be used to maintain 
databases; 3) allowing end-to-end recovery and flow control which therefore removes the 

15 need for the BBU to perform buffering and hnk layer maintenance; 4) allowing 

aggregation of multiple radio Hnks to increase throughput using MP; 5) allowing future 
development of new PPP extensions without requiring changes to the BBU/GS because 
the radio network just passes the packets through the GS; 6) enabling tunneling interfaces 
with other bearer services, allowing all communications to occur between the server and 

20 the GDG independent of the bearer service selected. 

For the CPE 492, three data hnk options can be selected depending on the type of 
data mode to be used. For a voice-grade data link, the CPE 492 can interface to the 
system via a V-series modem connected to a two-wire analog line from the LEC (local 
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exchange carrier). For packet data mode, the CPE 492 has two options. For a first packet 
data mode option, the CPE 492 can use a frame relay service if the CPE is part of an 
already existing frame network. Advantageously, a permanent virtual circuit (PVC) from 
each GS to a NATS data gateway over the existing frame network can be established to 

5 deliver IP packets from the aircraft (moving object). The CPE can act as a router 
connecting to the system with the server behind it, or alternatively the server can 
terminate the frame relay service and IP is transmitted over the Unk. For the second 
packet data mode option which provides lower costs, ISDN BRI service is obtained from 
the local exchange carrier (LEC). When IP packets are destined to the CPE, the GDG 

10 will set up the data link dynamically by calling to the CPE using PPP for IP 
encapsulation. 

An alternative bearer service used by the system can be a satelhte communication 
service. One example can be the INMARSAT DATA3 services which provides an X.25 
service with maximal data throughput (e.g., 10.5 Kbps) and is accessible through the 

15 SDU 195. FIG. 4 shows the connection options 500 for connecting the server to the 
SDU. Two options 510, 520 may use an ISDN D-channel to establish the X.25 SVC 
(switched virtual circuit) and transport the X.25 data packets. An alternative option 530 
can use the high-speed ARINC-429 port 145 to interface directly with the SDU for X.25 
call setup and data transport. 

20 Other alternative bearer services can be used including broadband satellite link 

services - for example, a DBS system. A suitable digital compression system, for 
example a Moving Picture Expert Group (MPEG-2) system, can be used to multiplex any 
digital signals with digitized video signals, including any packet data, on to one or to a 
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very small number of satellite transponders. Other compression methodologies may 
include, but are not limited to MPEG-4 (e.g, H.263, H.261) and other compression 
techniques including compression techniques that are standards compUant or proprietary. 
Use of a DSS system/interface unit allows for broadband communication 

5 independent of the particular link content, either a compressed video signal or a sequence 
of IP packets which can be deciphered by a video coding device at the GS and the DSS 
receiver on the aircraft. Passenger and cabin applications for this broadband satellite 
service include, but are not limited to, software downloading, flight information updates, 
Internet browsing, and TV/video delivery. 

10 FIG. 5 shows the architecture 600 of a satellite data communication service using 

DSS technology. The system architecture includes aircraft system 610 having server 615 
and CTU 612 for facilitating a conmiunications link to a DBS data center 630, via a DBS 
SateUite 618, and NATS network 620 interconnected to internet facilities 640 and CPE 
650. DBS data center 630 includes router 638, satellite access management system 637, 

15 DSS encoder 636, and radio equipment including combiner/uplink 635. The system 

architecture 600 further includes on the aircraft a DSS receiver/decoder and antenna (not 
shown) to help faciUtate the broadband service. 

The system architecture 600, using asymmetrical data transport, can provide large 
bandwidth (e.g., in excess of 5 Mbps) from the network (DSS, upstream) to the aircraft 

20 and from the aircraft to the network (e.g., 4.8-9.6 Kbps) (NATS, downstream). A large 
bandwidth for the upstream can be useful for web applications since most Internet 
browsing retrieves a much greater amount of information than is initially transmitted. 
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Alternatively, other satellite bearer services can be used to deliver data 
communication services, for example, LEO/MEO/GEO (low earth orbiting/middle earth 
orbiting/geosynchronous earth orbiting) satellite systems. Specific commercial examples 
of suitable LEO/MEO/GEO systems include, but are not limited to Iridium, Globalstar, 

5 ICO, Odyssey, Millennium, Space, Astrolink, Cyberstar, and Teledesic. Use of these 
systems enables data service offerings in the exemplary range of 384 Kbps - 1.2 Gbps, 
and allows various data applications including video conferencing, high-quality video, 
high-speed Internet, and virtual LAN service. 

FIG. 6 shows a representative example of a data conmiunication system 

10 architecture 605 using a LEO/MEO/GEO satellite network. The system architecture 605 
includes aircraft 610 having CTU 612 and server 615, with a data communication link to 
satellite network 685 and ground networks 695 via satelUtes 680, 690. The ground 
networks 695 can advantageously include GDG 694, video conference faciUty 691, VPN 
(virtual private network) 693, Internet facilities 640, and web server 692. The aircraft 

15 610 acts as one of the ground-based clients receiving and transmitting high speed data via 
the satelhtes 680, 690. The system 605 is a two-way system which alleviates the need to 
use the NATS network for a return path, and allows the server 615 to treat the satellite 
Hnk as just another two-way bearer service by using the satellite broadband network 685 
to interconnect the aircraft 610 and the ground networks 695, via a mobile terminal (MT) 

20 (not shown) connecting to the ground networks 695. 

The satellite network 685 can perform necessary routing and handoff procedures 
to establish and maintain connectivity between the aircraft 610 and ground networks 695, 
Additionally, the satellite network 685 can serve as a network cloud providing 
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connectivity between any pair of clients (e.g., aircraft 610 and ground networks 695) 
preferably using SVCs or PVCs. 

The aircraft 610 includes a satellite transceiver unit capable of transmitting and 
receiving data using any particular satellite network, and having the capability of 

5 handhng either ATM or frame relay protocol such that a SVC or PVC can be established 
between the aircraft transceiver box and ground networks 695. Using this setup, IP 
packets can be encapsulated by these lower layer protocols to enable a transparent 
conduit for IP packets to travel from the aircraft to the desired ground networks 695. 
Another alternative data link option enables passenger cabin dial-up access 

10 services. FIG. 7 shows the communication system architecture 148 for passenger cabin 
dial-up services. The system architecture 148 includes cabin distribution system 150, 
server 110 having its components, and can further include digital flight data acquisition 
unit (DFDAU) 710, ACARS MU 750, and other components. 

The system 148 allows a user (passenger) to access internet service, either via an 

15 on-board intemet service or using the server as a proxy to access the rest of the Internet. 
At least two types of access are available depending on the configuration of the user's 
access device (e.g., laptop). For all access scenarios, the connection to the server 110 via 
the TS fianction will be over a CTU-switched ISDN B-Channel. Advantageously, the 
user's access device can be equipped with a PCMCIA V-series modem allowing 

20 connection to an RJ-1 1 jack on the handset, and the handset can be connected to the CTU 
1 52 via the CDS network. For this configuration, a modem pool, as part of the TS 
function, can peer with the laptop modem, and the link layer protocol is PPP so that 
proper authentication (for billing purposes) and dynamic IP address assignment can be 


achieved. Advantageously, a useful COTS TS for serving this function includes, but is 
not limited to, the Ascend MAX or US Robotics Total Control that, on one end, can 
interface with the CTU via a Tl/El PRI or with the BBU via a BRI and, on the other end, 
with the server via Ethernet (see FIG. 1) 

5 Alternatively, the user's access device can be equipped with an ISDN modem, 

alleviating the need for the server 110 to have modem capability. In this configuration, 
an internal COTS PRI PC card can be used for handling the end-to-end digital signal. 
Advantageously, this particular configuration imposes no additional development on the 
aircraft end, only requiring modification on the handset to provide a U-interface for 

10 connecting to the user access device ISDN modem. 
Networking 

FIG. 8 shows a more detailed illustration of the server data link option to the 
ground using the existing voice-grade NATS network. This system architecture 900 
includes access device (e.g., laptop) 910, server 920, DAU 925, BBU 930, modem 937, 
15 and RFU 935 as part of the air portion of the architecture 900, and RFU 940, BBU 945, 
modem 955, switching center 950, PSTN 960, and terminal server (TS) 965 as part of the 
ground portion of the architecture 900. 

As described previously, a point-to-point Hnk can be estabUshed between the 
aircraft and remote server using the PPP link layer protocol to encapsulate IP for transfer 
20 across this virtual connection. The data link can be established in three stages, using an 
air-to-ground link request, ground-to-ground call setup, and end-to-end call setup. 

Advantageously, the air-to-ground link can be first requested using a FAX/DATA 
channel request signal via the DAU 925 to the BBU 930. BBU 930 can determine which 
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ground station to use and can then send a request channel signal, via RFU 935, to the 
ground station (GS) selected. Once the selected GS finds an available channel, the OS 
sends a request to the switching center (SC) 950, receives an acknowledgment, and then 
returns the acknowledgment with the assigned channel to BBU 930, via BBU 945 and 

5 RFU 940. After receiving the acknowledgment signal, BBU 930 sends a signal to server 
920 via DAU 925 indicating that a channel is being made available. Upon completion of 
this air-to-ground link request (channel availability), the voice path can be estabhshed 
between the server 920 and the SC 950, and the SC 950 inserts an in-band dial-tone and 
waits for the server 920 to out-pulse in-band DTMF digits to complete the ground portion 

10 of the call coimection. 

Once the air-to-ground call setup is completed, the ground-to-ground call setup 
can then proceed. Once the server 920 receives the "dial-now" signal, it then out-pulses 
the 10-digit phone number to the SC. The SC then connects to the destination number 
via the PSTN and bridges the two conference legs together. At this point, the SC returns 

15 the call progress tone all the way back to the server 920. Upon answering the call, the 
remote TS 965, either at the GDG or the CPE, sends the in-band modem answer tone, via 
modem 955, to start the modem negotiation with the calling party, via modem 937. Once 
the GS detects the modem tone, it cuts the voice path, and sends a signal to the BBU 945 
to request it to start modem training with the server 920. At the same time, the GS starts 

20 the modem training with the TS 965. When both pairs of modems 937, 955 complete the 
training, the data can flow through the air link using a particular out-of-band protocol 
while the data flowing between the two pairs of modems can use a V-series protocol. 
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Once the setup of the physical layer between the server 920 and TS 965 is 
completed, the TS 965 can start the link layer negotiation with the server using the PPP 
protocol in accordance with RFC 1548, 1549 including the three main components of 
PPP: LCP (Link Control Protocol), NCP (Network Control Protocol), and multi-protocol 
5 encapsulation. PPP encapsulation frames can be used to carry the IP traffic across the 
data link between the two PPP peers, the server 920 and the TS 965 of the ground 
network. Advantageously, the server 920 may act as a proxy server or perform network 
address translation for any chents on the same LAN. 

FIG. 9 shows a more detailed illustration for the packet data connections using the 
10 NATS network. The hnk architecture 1000 includes server 1005, CTU 1008, ACU 1010, 
GS 1015, GDG 1020, and CPE 1025. Different data link protocols can be followed over 
different link segments. Advantageously, a call scenario can start when the server 1005 
needs to establish a data link to the ground IP network. When the BRI is used, the server 
will send out a call setup request via the D channel to the BBU with data call indication. 
1 5 The BBU will then request a traffic channel from the GS 1 0 1 5 for data use. Once the GS 
allocates a channel and acknowledges the BBU, the BBU will send back the call 
connected Q931 message back to the server 1005 and allocate the B channel for such use. 
All subsequent IP data will go over this clear B channel using PPP to frame the IP 
packets. 

20 Alternatively, if the ISDN PRI is used instead for call setup, the call request can 

be initiated when the server sends a call setup message to the CTU 1008 as described 
previously. CTU 1008, based on the destination number of the call setup message, will 
send an incoming data call indication to the BBU. Once the BBU detects the incoming 
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call event, it will proceed and negotiate a traffic channel as described previously. Once 
the channel is allocated, the BBU will send back call answer messages to the CTU to 
inform the server 1005 that a data link is up and it is ready to receive any PPP packets. 
Once the PPP packet arrives at the BBU, the BBU will strip off the PPP header from the 
PPP packet, put the remaining PPP packets into RF frames, and transmit the channel- 
encoded RF firames over the radio link to the GS 1015. 

Once the GS 1015 receives the radio frame, it will recover the IP packet and 
forward it to the GDG 1020, advantageously serving as a router and interface to the 
public Internet and to the private network that interconnects the CPE servers such that 
every IP packet will be routed to the appropriate network based on the destination IP 
address. For ground-to-air packet data calls, the GDG will send call request messages to 
the associated GS for certain destination air terminals via a frame relay network. When a 
radio link is available, a connection will be set up from GDG to server (using circuit 
mode from GS to server). 
Circuit Mode Data in the Packet Data Network 

The packet data architecture described herein can be used for an improved circuit 
mode data solution (non-CTU installation). The circuit mode data system architecture 
1 100 is shown in FIG. 10. The system architecture 11 00 includes user access device 
(e.g., laptop) 1105, telephone 1110, ACU 1115, TS 1125, antenna 1120, radio tower 
1135, server 1130, ground station controller (GSC) 1140, router 1145, frame relay 1150, 
router 1 155, GDG 1 160, modem pool 1 156, PSTN 1 170, and destination modem 1 175. 

FIG. 1 1 illustrates the call flow procedures 1200 for the cfrcuit mode data solution 
for the packet data network. In accordance with embodiments of the present invention. 


the circuit mode data solution can use a TCP/IP interface to be constructed between the 
server and the GDG. The call flow 1200 includes a plurality of components including 
user access device (e.g., handset) 1205, TS 1210, server 1215, BBU 1220, GSC 1225, 
GDG 1230, and remote end device 1235. 

5 Upon user request from the user access device 1205, the BBU 1220 can check to 

verify that adequate radio and server resources are available. Assuming adequate 
resources are available, the BBU 1220 will then proceed to reserve a modem on the TS 
1210 and establish a link to the GSC 1225. Once the Hnk to the ground is estabhshed, an 
end-to-end TCP circuit is setup between the appropriate GDG 1230 and TS 1210 

10 components, advantageously performed using telnet or a socket connection between the 
two components. The BBU 1220 also forwards dialing and dialed numbers to the GDG 
1230. Pending a sanity check on the dialed number and a validation check on the biUing 
instrument, the GDG 1230 will initiate a connection to the desired destination party via a 
modem. Simultaneously, the BBU 1220 will transfer the call to the TS 1210 voice-band- 

15 data BRJ interface with both modem connections (i.e., passenger to TS 1210 and GDG 
1230 to remote end device) negotiating the link separately. Upon confirmation that these 
two links have been established, the GDG 1230 and TS 1210 can shuttle information to 
each other. Additionally, this configuration can support handoffs of voice-band-data 
calls. 

20 

Server Software Architecture 

As illustrated in FIG. 12, the server of the data communication system can 
advantageously include an object-oriented software architecture 1400. Software 
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architecture 1400 includes server 1410, GDG 1430, and ground-based servers 1440. An 
object-oriented software architecture is exemplary and alternative software architectures 
may be used including, but not Umited to, C++, JAVA, HTML, etc. 

Use of an object-oriented design includes that each system resource or service 
5 provider bears an object entity, and that services are accessible via the published 

methods. Resources are managed within the objects. Additionally, the server 1410 may 
advantageously use a chent-server model wherein the clients request the service by 
accessing the pubhshed methods or interfaces on the servers 1440. The software 
architecture also advantageously may use location transparency wherein the objects are 
10 accessible by the chents universally within the confines of the access control and the 
network connectivity. 

As shown in FIG. 12, the software architecture 1400 may optionally include GUI 
(Graphical User Interface) 1420 having interfaces allowing data communication 
appUcations to request services from the server 1410. Preferably, objects on server 1410 
15 can advertise services that applications are allowed to access, the appUcations also 

accessing a Structured Query Language (SQL) manager as needed to interact with the 
GDG 1430 to retrieve or send data. The GDG 1430 may serve as a Data Proxy, using 
local storage space to either cache the data for upload to the server 1410 or download to 
the customers' (user) ground-based servers (GBS) 1440. GDG 1430 will then use the 
20 proper transport to interact with the GBS 1440 for data transfer. The GUI 1420 can be 
optional to the design as applications may run unattended without human intervention 
and therefore are only used for maintenance operations under those conditions. The 
design of the architecture 1400 is independent of the underlying operating system. 
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The software architecture can be logically divided into four functional layers 1500 
as shown in FIG. 13. These layers include an applications (AP) layer 1505, application 
programming interface (API) layer 1510, system services (SS) layer 1515, and system 
resources (SR) layer 1520. The AP layer can contain applications that are developed by 

5 the aircraft or other parties. The SR layer contains the system resources that are used by 
the SS layer when providing service to higher layer components. The SR components 
can include the server bearer resources, the databases, the data storage, and JAVA 
execution environment, etc. 

The SS layer components provide system-level services to the objects in the API 

10 layer or to other components in the same layer. The services can include, but are not 
limited to, various TCP/IP services, avionics standards services, data compression and 
cryptographic services, scheduling, and transaction-oriented services. The SS layer 
includes API administration SS to manage all API objects, its purpose being to provide 
access control, service activation/deactivation, and property change capabilities of the 

15 API object to the data communication service provider. 

Advantageously, the SR layer may include at least four types of components used 
by the data communication server. These components can include device drivers, BITE 
system, file system, and miscellaneous facilities. Dependent on the underlying OS of the 
data communication server, the components of the SR layer may be part of the embedded 

20 OS or may be specially designed for aircraft data communication services. 

Device drive (DD) components enable the SS layer components to interact with 
communication devices for data exchange with the GDG or with onboard avionics 
devices. Advantageously, the DD may be part of the underlying OS or may be specially 
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developed, and includes a plurality of components including a BRI driver, PRI driver, 
Ethernet driver, ARINC-429 driver, and ARINC-573 driver. 

The SR file system can advantageously provide a consistent way to store (or 
provide permanent storage - persistence) the data, including allowing the SS components 

5 to perform read, write, and delete operations based on particularly developed user rights 
or permissions. Additionally, the file system can include a special system file, the route 
table, used for determining the routing for IP packets. The route table can include a set of 
known routes and be locally stored in non- volatile memory. 

Miscellaneous facilities can include an SQL database and a JAVA Virtual 

10 Machine (VM). The SQL database provides a database engine to store and manage the 
data needed by the server SS and API components, including all necessary database 
transactions such as query, insert, update, and delete functions. Advantageously, the 
JAVA VM can allow the server to access other network-based services using JAVA 
applications or applets. Use of the VM allows the server to write an API using JAVA 

15 architecture that allows chents firom other platforms running a different OS to request 
services fi:om the data communication server with a standardized protocol. 

The API layer provides a consistent way for the AP to acquire and utilize data- 
oriented aircraft services. Advantageously, a generic object is produced, an example 
being the generic business object (BO), that will allow access to these services assuming 

20 specific transport protocols (e.g., TCP/IP, UDP, etc.). This allows use of an object 
without specific knowledge of the service support structure. Alternatively, each 
component in the API layer can be represented as an object that provides one specific 
aircraft service, each object containing three major parts - the communicator, the 
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receptor, and the service logic. Services provided by each API object can be 
characterized by properties, methods, and events and are exposed through the 
communicator and the receptor. 

The communicator is a cHent-side component which can be represented as a 

5 control in a user object (UO), or the object embedded in AP, which enables the AP to 
invoke services and to communicate or share the data construct with the object via a 
known set of properties, methods, and events. The receptor component which can be 
represented as a control in the business object and which resides inside the object itself, is 
used to accept the service requests and to share and communicate back with the AP. The 

10 service logic is the implementation of the object itself and has access to the lower-layer 
components. This architecture is illustrated in FIG. 14 and comprises the client process 
1605 and the local server process 1618. Ghent process 1605 includes cUent appUcation 
1610 and user object 1615, and local server process 1618 includes business object 1620 
and local server 1625. 

15 Other API objects can include Objects to retrieve updatable or time-sensitive 

information for a user, information that may lose its value if not retrieved by the user in a 
pre-determined period of time, and information that may be updated as a result of this 
value loss. This updatable or time-sensitive information for the user may include news 
information, sports scores, weather information, traffic information, politics information, 

20 business information, finance information, and other updatable or time-sensitive 

information. Other objects may include FMS (Flight Management System) Object for 
database loading, the FOQA (Flight Operations Quality Assurance) object for obtaining 
and managing ACMS data, and other objects. 
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In practical operation, the communicator can provide the cHents the necessary 
networking and protocol handling capability to execute services on the server, and the 
receptor handles the requests initiated by the clients and starts "Instances" of the services 
being requested. Following this process, the communicator of the API allows the 
5 applications to make use of the services provided by the server. Similarly, the 
communicator of the SS object allows other SS and API components to utilize the 
services provided by the SS object. 

FIG. 15 shows a representative example of the functional layer process 1700 for 
an exemplary application, a sports score application. A similar process can be followed 
10 for other appUcations to retrieve updatable information. The functional layer process 
1700 includes a plurality of components including chent 1705, admin server 1710, file 
system SR 1730, retriever SS 1715, BRI SR 1725, Database SS 1722, IP stack SS 1735, 
and GDG 1720. 

For this example, a sports score retrieval SS 1715 is advantageously registered 
15 with the scheduler enabling execution periodically to retrieve sports scores from the GDG 
1720. A sports scores admin server 1710 instantiates sports scores API objects 1712 and 
makes them available for the sports score chents 1705 to obtain sports scores for the user. 
A Database SS 1722 is used by sports scores API1712 and retriever 1715 to store 
(persist) and share the scores files, advantageously stored in a user profile. It is also used 
20 by the retriever 1715 to initiate an SQL query, via the IP Stack SS 1735 and BRI SR 
1725 (or alternatively, an Ethernet SR), to the GDG 1720 to retrieve the latest cached 
scores. 


27 


FIG. 16 illustrates an exemplary configuration for the software architecture 1800 
for an end-to-end system between the cockpit and cabin terminals 1870, airborne data 
server 1875, and ground data gateway 1880. 

The sports scores admin server 1710 allows a system administrator to perform a 

5 plurality of fiinctions including starting/terminating the sports scores service, changing 
the property of each active instance and the default property of the service, changing the 
automatic update schedule using the sports scores retriever 1715 control, and initiating an 
on-demand update using the sports scores retriever 1715 control Additionally, the admin 
server 1710 maintains the database that contains all the sports scores records wherein 

10 advantageously the client API can be allowed access to database records with ''read" 

permission only, and both the admin server 1710 and the retriever 1715 have full control 
over the records. 

The sports scores retriever 1715 advantageously can have access to both the 
sports scores database and the sports scores locator database. The retriever 1715 can use 

15 the information in the locator database to construct the SQL queries, such as the token 
representing the records desired, the SQL server location, and the property of the records, 
and other information to retrieve the sports scores records. The retrieved information will 
be written to the sports scores database, and a proper event will be sent back, either to the 
client 1705 or the admin server 1710, to inform the availabihty of the updated records. 

20 Additionally, a GUI will be available to a system administrator to perform a plurality of 
functions including initiating a complete on-demand update, initiating a partial on- 
demand update based on the cUent property forwarded, allowing modifications to the 
automatic update schedule, and changing the locator database records. 
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FIGs. 17-19 provides a representative example of the administration, client, and 
retriever control properties of the server control part of the API categorized by property 
name, type, allowable value, and comment. 

In practical operation, the client requests services via methods. Advantageously, 
a generic method may be created but with different properties to differentiate various 
services requests, or different methods may be created to represent different requests. 
FIGs. 20-21 provides a representative example of the different server-side and client-side 
methods that can be created for the sports scores API. 

Additionally, clients can request an object to send notification in case a specific 
event has occurred. Advantageously, the client is notified of an event in the form of 
executing the call event function on the client side. For the exemplary sports scores API, 
there are two events that can be required, one for indicating the successful completion of 
"method" execution, and another for indicating when the "method" execution failed. 
Optionally, an error code may be used as part of the event to indicate the cause of the 
failure. 

Referring again to FIGs. 15, 17-21, an illustrative example of how sports scores 
AP invokes the data communication server's sports scores service and the actions 
performed as characterized by properties and methods are shown. 

Initially, for the "client requests for scores" action 1706, the user can select the 
desired options on the property menu via the GUI and demand an unconditional update 
(see FIG. 22). Then, for the "server retrieves data requested" action 1707, the server-side 
Sports Scores API 1712 reviews the client-controlled property (see FIG. 19) and initiates 
an SQL query of the sports scores table via the SQL Manager SS to verify that data is up- 


to-date. For this example, the SQL query suggest that the data requested is out-of-date. 
Next, in the "server requests for updates" action 1708, the server-side sports scores API 
1712 demands an update (see FIG. 21) which invokes the sports scores retriever SS 
server 1715 control using the retriever control property (see FIG. 20). Then, for the 

5 "retriever initiates SQL-based scores retrieval" action 1709, the sports scores retriever SS 
component 1715 invokes SQL Manager control to query the sports scores locator records 
for detailed instructions to initiate an SQL-based data query (e.g., SQL script ED). Then, 
the retriever 1715 instructs the SQL Manager to retrieve the required data records. Then, 
for the "low-level SQL queries and retrieval" action 171 1, the SQL Manager initiates 

10 queries by establishing an SQL port, TCP or UDP, connection to the SQL server inside 
the GDG 1720. 

The request can be wrapped by the IP Stack SS 1735 and can be sent to the proper 
BRI SR 1 725 that has the connection to the desired bearer via the routing table lookup. 
The SQL query requests that an IP packet be delivered to the GDG 1 720 where 

15 corresponding TCP/UDP ports are being used for accepting the SQL connections. 

Advantageously, the SQL server on the GDG 1720 returns the results of the query back 
to the database SS 1722. The sports scores retriever 1715 receives an event notification 
of the completion of the query. 

For the "sports scores retriever notifies server of task completion" action 1713, 

20 the sports scores retriever sends a completion event to the Server by executing a call-back 
function. Then, for the "server reads database records" action 1714, the server API, 
embedded as part of the call back function, contacts the database manager for the 
requested sports scores wherein the retrieved data is delivered to the client side sports 
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scores API object 1705. Then, for the "cHent reads scores" action 1716, the client-side 
API 1705 receives the completion event and retrieves the data delivered by the server- 
side API 1712 wherein the results (updated sports scores) are presented to the user via the 
client GUI controls. 

5 

Applications 

Several applications are enabled by the data communications system architecture 
including aircraft operations applications, cabin applications for aircraft personnel, and 
passenger applications. Advantageously, many of the applications use a display 

10 observable to the aircraft crew or passenger to display requested or automatically 

generated information (e.g., catalog of products or services) via the data communication 
server, and provides for delivering information (e.g., credit card) to facilitate a purchase . 
Operations applications are intended to increase the operational efficiency of the airline 
flight crew, flight operations, department, and/or maintenance department in the 

15 operation and maintainability of the aircraft. Operations applications can include, but are 
not limited to, electronic library systems (ELS)/electronic logbook, flight operations 
quahty assurance (FOQA), engine data, performance reports (VI speeds, rotation angle), 
aircraft position, out, off, on , in (OOOI)/flight phase reports, and data loader. Further 
operations applications may include aircraft condition monitoring system, fault reports, 

20 gate assignment, weight data, departure reports/pre-flight briefings, clock 

synchronization, delay reports, gate requests, ACARS, crew scheduling, and weather. 

The ELS/electronic logbook provides a paperless environment for the aircraft 
crew to manage aircraft operations. The system includes reference to on-line manuals 
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and guides and provides an electronic mechanism for items requiring logbook entry. 
Logbook entries can be automatically sent to the aircraft operations center for an updated 
copy of the logbook system, this copy serving as a backup to the electronic copy kept on 
the aircraft system. 

5 FOQA is an FAA-sponsored program to increase aircraft flight safety via 

monitoring aircraft and pilot performance through the various data supplied by the 
aircraft sub-systems. The data can be stored on-board the aircraft and dehvered at a later 
date to aircraft flight operations or can be delivered real-time via the data 
communications server. The engine data application can include real-time delivery of 

10 engine performance data to the aircraft operations center, obtainable via the ACARS MU 
or via the ARINC-429 bus connected to an engine electronic controller (EEC). 
Performance reports may include monitoring of pilot actions during critical phases of 
flight such as takeoff and landing to provide the flight operations input for corrective 
actions in training programs or technical literature. Additionally, data analysis used to 

15 maximize flight performance may include monitoring of such data as actual vs. 

calculated VI speeds, angle of rotation, flap deployment, and angle of ascent/descent. 

Real-time aircraft position is used by the aircraft operations center to track the 
aircraft and provide real-time feedback for performance monitoring and route 
adjustments to pilots. Advantageously, the data communications server may obtain 

20 position information fi:om an on-board positioning system (e.g., global positioning 

satellite) and route that information to the aircraft operations center. Other applications 
use the data communication server to provide the requested data. 
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Cabin applications can be advantageously intended to increase the operational 
efficiency of the aircraft cabin crew and/or maintenance crew. Cabin applications can be 
also intended to provide new passenger services or more efficient use of existing 
passenger services. Cabin applications can include, but are not limited to, connecting 

5 gates/delay reports, duty-free shopping (allowing aircraft personnel to validate credit 
purchases of duty-free goods via a card reader), frequent flyer/customer profile, on-board 
inventory, systems information and troubleshooting, departure reports/pre-flight 
briefings, FA communication system, flight attendant comments tracking system 
(FACTS), email, cabin discrepancy log (CDL), catering reports (allowing user pre- 

10 selected catering services), and baggage/asset tracking. Baggage/asset tracking can be 
advantageously implemented using the data communication server in combination with 
an RFID tag system (e.g., integrated into baggage tags) to track and locate aircraft 
baggage and assets. The RFID tags could be read with RF readers for tracking and 
identifying of baggage and assets, including a data link (e.g., Ethernet) to the data 

1 5 communication server for processing. 

Passenger applications are intended to provide a more comfortable, convenient 
aircraft experience for the passenger (user). Passenger applications can advantageously 
include, but are not limited to, transaction processing, sports scores as described herein, 
connecting gates/delay reports, service selections, reservation system access, messaging 

20 service, marketing tracking, surveys/comments, shopping, email, advertising, on-line 
services as described herein, passenger inflight information (PII), GTA registration for 
telephony services, and medical information. 


Although the invention is described herein using the NATS network as a primary 
bearer service for an aircraft data communication service, it will be appreciated by those 
skilled in the art that modifications and changes may be made without departing from the 
spirit and scope of the present invention. As such, the method and apparatus described 
herein may be equally applied to any bearer service providing data communication 
services for a user from any moving object. 


